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1  Introduction 


An  SDTS  profile,  in  general  terms,  is  defined  as  a  limited  subset  of  the  Spatial  Data  Transfer 
Standard,  designed  for  use  with  a  specific  type  of  data.  Specific  choices  are  made  for 
encoding  possibilities  not  addressed,  left  optional,  or  left  with  numerous  choices  within  Parts 
1,  2,  and  3  of  SDTS. 

An  SDTS  profile  shall  provide  for  the  transfer  of  files,  records,  fields  and  subfields  with  the 
following  objectives: 

(a)  to  encode  in  a  standard  format; 

(b)  to  provide  for  machine  and  media  independence; 

(c)  to  accompany  the  data  with  their  description; 

(d)  to  preserve  all  meaning  and  relationships  of  the  data;  and 

(e)  to  keep  both  fields  and  records  to  an  appropriate  maximum  length. 

1.1  Scope  and  Definition 

Part  4,  the  Topological  Vector  Profile  (TVP),  contains  specifications  for  an  SDTS  profile  for 
use  with  geographic  vector  data  with  planar  graph  topology. 

1.1.1  Geographic  Data 

By  "geographic"  we  mean  data  that  describe  "real-world"  features,  rather  than  a  symbolized 
map  graphic.  The  data  may  be  derived  from  a  cartographic  product  (map),  but  the  purpose  of 
the  data  is  not  to  convey  the  map  graphic,  but  rather  information  about  the  geographic 
features  displayed  on  the  map. 

1.1.2  Vector  Data  with  Planar  Graph  Topology 

The  data  are  represented  by  vector  objects  which  comprise,  or  are  integrated  with,  one  or 
more  2-D  manifolds  (see  Part  1  definition  2.3.4.5.2).  Excluded  are  raster  data,  geometry-only 
vector  data,  planar  graphs  which  do  not  have  GT-polygons,  and  non-planar  graph-based 
network  data.  These  types  of  data  may  be  accommodated  either  by  other  profiles,  or  future 
extensions  to  this  profile. 

Part  4  is  organized  using  the  same  major  headings  found  in  Part  1.  Specific  discussions 
regarding  encoding  possibilities  in  Part  1  are  grouped  under  each  major  heading  and  will 
include  specific  references  to  Parts  1,  2,  or  3  where  necessary  for  clarification. 
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1.1.3  Profile  Annex  Options 

Annexes  D,  E,  and  F  of  Part  4  contain  permitted  options  to  this  profile.  These  options 
implement  additional  features  of  the  SDTS  which  may  be  useful  in  some  transfers.  Encoders 
and  decoders  are  not  required  to  implement  these  options  to  be  conforming  to  this  profile. 
However,  the  presence  of  these  options  shall  be  tolerated  by  decoders. 

1.2  Conformance 

(see  also  Part  1,  Section  1.2,  Conformance) 


There  are  three  types  of  products  which  can  be  tested  for  conformance  to  this  profile: 

(a)  SDTS  transfers  (the  actual  data  sets); 

(b)  SDTS  encoding  software;  and 

(c)  SDTS  decoding  software. 

1.2.1  Transfer  Conformance 


In  order  to  conform  to  this  Topological  Vector  Profile,  an  SDTS  transfer  shall: 


(a) 


contain  all  mandatory  spatial  objects,  modules,  fields,  and  subfields  as  specified 
in  this  profile; 


(b)  not  contain  spatial  objects,  modules,  fields,  and  subfields  which  are  not 
permitted  by  this  profile  or  its  annexes 


(c)  conform  to  all  requirements  and  specifications  of  Parts  1,  2,  and  3  of  SDTS 
unless  they  conflict  with  this  profile; 


(d)  conform  to  all  restrictions  on  SDTS  Parts  1,  2,  and  3  as  specified  in  this 
profile; 

(e)  be  formatted  in  compliance  to  ANSI/ISO  8211; 

(f)  contain  2-dimensional  manifolds  which  conform  to  constraint  rules  as  defined 
in  Section  2. 3.4.5  of  Part  1  of  SDTS; 


(g)  contain  all  topological  pointers  required  by  this  profile; 

(h)  contain  only  data  sets  which  have  level  1  External  Spatial  Reference 
conformance; 

(i)  follow  all  module  and  file  naming  requirements  of  this  profile; 
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(j)  contain  any  profile  options  it  claims  to  include;  and 

(k)  adhere  to  all  other  requirements  specified  in  this  profile. 

1.2.2  Encoder  Conformance 

In  order  to  conform  to  this  Topological  Vector  Profile,  an  SDTS  encoder  shall: 

(a)  generate  only  SDTS  Topological  Vector  Profile  transfers  which  conform  to 
Section  1.2.1  (or  be  able  to  be  directed  to  only  generate  transfers  which 
conform  to  this  profile); 

(b)  convert  spatial  objects  in  the  input  system  to  appropriate  SDTS  spatial  objects; 

(c)  convert  attribute  data  stored  in  the  input  system  (such  as  in  a  data  base)  to 
SDTS  Attribute  Primary  and  Secondary  modules; 

(d)  correctly  maintain  linkages  between  spatial  objects  and  attributes; 

(e)  correctly  maintain  or  generate  required  topological  pointers;  and 

(f)  support  all  profile  options  it  claims  to  support. 

1.2.3  Decoder  Conformance 

In  order  to  conform  to  this  Topological  Vector  Profile,  an  SDTS  decoder  shall: 

(a)  be  able  to  interpret  Topological  Vector  Profile  transfers  which  conform  to 
Section  1.2.1; 

(b)  be  able  to  decode  any  module  required  or  permitted  by  the  body  or  Annex  A 
of  this  profile  (decoding  of  modules  permitted  by  Annexes  D,  E,  and  F  is 
optional); 

(c)  be  able  to  decode  any  spatial  object  required  or  permitted  by  section  2. 1  of  the 
profile  and  "PR",  "PU",  and  "PV"  GT-polygon  spatial  objects  permitted  by 
Annex  E  and,  to  the  fullest  extent  possible  in  the  output  system,  convert  it  to  a 
corresponding  object  or  equivalent  information  structures  in  the  output  system; 

(d)  be  able  to  decode  any  Attribute  Primary  or  Secondary  module  and  convert  it  to 
a  data  base  or  other  format  usable  by  the  output  system; 

(e)  correctly  maintain  linkages  between  spatial  objects  and  Attribute  Primary 
records; 
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(f)  be  able  to  ignore  modules,  fields,  and  subfields  which  are  permitted  only  by 
profile  annexes  which  it  chooses  not  to  implement; 

(g)  be  able  to  recover  if  an  error  is  encountered  in  a  particular  record,  field,  or 
subfield  in  the  SDTS  transfer; 

(h)  report  to  a  file  or  output  device  information  describing  the  position  of  errors 
encountered  in  the  SDTS  transfer,  including  Module  Name,  Record  ID,  tag,  and 
label  of  the  last  successfully  decoded  data  element  and,  if  possible,  the  Module 
Name,  Record  ID,  field  tag,  and  subfield  label  of  the  data  element  containing 
the  error;  and 

(i)  support  all  profile  options  it  claims  to  support. 

1.3  Changes  to  Parts  1  and  3  Requirements 

The  following  is  a  summary  of  the  changes  to  Parts  1  and  3  of  FIPS  PUB  173  that  become 
effective  along  with  this  addition  of  Part  4  to  FIPS  PUB  173-1: 

(a)  many-to-many  and  many-to-one  relationships  between  spatial  objects  and 
attributes  are  permitted  (Section  5.3); 

(b)  composite  objects  which  do  not  contain  component  objects  are  permitted 
(Section  5.4); 

(c)  the  Entity  Authority  and  Attribute  Authority  subfields  in  the  Data 
Dictionary/Schema  module  may  contain  a  maximum  of  8  characters;  if  Part  2 
of  the  SDTS  is  the  source  of  a  definition  the  subfield  shall  contain  "SDTS- 
USA";  a  provision  for  standard  feature  registers  of  other  countries  has  been 
added  (Section  5.12); 

(d)  the  Attribute  Authority  subfield  in  the  Data  Dictionary/Domain  and  Data 
Dictionary/Definition  modules  may  have  a  maximum  length  of  8  characters 
(Sections  5.13  and  5.14); 

(e)  the  External  Spatial  Reference  subfield  in  the  Conformance  field  in  the 
Identification  module  shall  have  a  null  value  meaning  "undefined,  not  relevant" 
when  used  in  a  transfer  containing  only  a  master  data  dictionary;  it  is 
acceptable  to  specify  this  by  omitting  this  subfield  (Section  A. 2.2); 

(f)  in  the  Point-Node  module,  the  Attribute  ID  field  is  not  mandatory  for  objects 
"NE"  and  "NL”  (Section  5.5.4); 

(g)  in  the  Line  module,  Annex  D  allows  the  simultaneous  use  of  both  the  Chain 
Component  ID  and  Spatial  Address  subfields  (Section  D.6.2);  and 
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(h) 


the  ISO  8211  tag  for  the  Primary  Field  of  the  Arc  module  shall  be  ARCC 
(Section  D.7.2). 
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2  Spatial  Data  Concepts 

(see  also  Part  1,  Section  2,  Spatial  Data  Concepts) 

2.1  Spatial  Objects 

(see  also  Part  1,  Section  2.3,  Definition  of  Spatial  Objects) 

The  following  table  indicates  which  spatial  objects  are  required,  optional,  or  not  permitted  for 
this  profile. 


Object  Representation  Code 

Required 

Optional 

Not  Permitted 

NP  -  Point1 

X 

NL  -  Label  point 

X 

NE  -  Entity  point2 

X 

NA  -  Area  point2 

X 

NO  -  Node,  planar2 

X 

NN  -  Node,  network 

X 

LQ  -  Link 

X 

LS  -  String3 

X 

LE  -  Complete  chain2 

X 

LL  -  Area  chain 

X 

LW,LY  -  Network  chain 

X 

AC,AE,AU,AB  -  All  arcs3 

X 

RM  -  Ring  with  mixed 
composition 

X 

RS  -  Ring  composed  of  strings 

X 

RU  -  Ring  composed  of  chains4 

X 

RA  -  Ring  composed  of  arcs 

X 

PG  -  G-polygon 

X 

PC  -  GT-polygon2 

X 

'Points  with  the  "NP"  object  representation  code  are  allowed  only  for  use  in  data  quality  reports. 

2Each  of  these  objects  must  participate  as  a  component  of  a  2-D  manifold. 

’Allowed  only  as  an  option  as  described  in  Annex  D. 

4Allowed  only  as  an  option  as  described  in  Annex  E. 
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Object  Representation  Code 

Required 

Optional 

Not  Permitted 

PR  -  GT-polygon4 

X 

PU  -  Universe  polygon4 

X 

PW  -  Universe  polygon2 

X 

PV  -  Void  polygon4 

X 

PX  -  Void  polygon2 

X 

GI,GJ,GK,GM  -  Raster  objects 

X 

FF  -  Composite 

X 

2.2  Layers  and  (or)  Partitions 

Data  are  to  be  represented  by  one  or  more  2-D  manifolds  (see  Part  l  definition  2. 3.4. 5. 2).  A 
single  2-D  manifold  shall  be  used  to  transfer: 

(a)  one  theme  (or  sub-theme),  or  an  integrated  set  of  themes,  as  a  "vertical"  data 
layer  (see  Part  1  definition  2.3.4.3);  within 

(b)  one  horizontal  partition  of  the  earth’s  surface.  This  partition  may  be 
representative  of  a  map  sheet  (e.g.  a  USGS  quadrangle),  an  administra¬ 
tive/political/study  area  unit,  or  a  sub-partition  thereof. 

More  than  one  layer  and  (or)  more  than  one  horizontal  partition  may  be  included  within  a 
single  SDTS  transfer.  See  Section  4.7  of  Part  4,  "Relationships  Between  Modules  and  2-D 
Manifolds"  for  information  on  module  requirements  when  transferring  multiple  2-D 
manifolds. 
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3  Spatial  Data  Quality 

(see  also  Part  1,  Section  3,  Spatial  Data  Quality) 

3.1  Lineage 

Separate  processing  histories  pertaining  to,  for  example,  separate  data  layers,  shall  be 
documented. 

3.2  Positional  Accuracy 

If  data  are  collected  from  a  graphic  map,  then  a  statement  explaining  that  the  data  may 
contain  cartographic  offsets  shall  be  included  in  the  positional  accuracy  portion  of  the  data 
quality  report. 

3.3  Logical  Consistency 

The  technique  used  to  verify  topology  shall  be  documented. 

3.4  Completeness  and  (or)  Logical  Consistency 

Report  and  explain  data  encoding  practices,  especially  in  object  records,  which  might  seem 
contrary  to,  or  to  deviate  from,  normal,  standard  or  preferred  practices.  For  example,  if  one 
or  more  composite  object  records  lack  lists  of  component  objects,  the  meaning  of  this  shall  be 
explained  in  the  completeness  portion  of  the  data  quality  report. 
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4  General  Specification  (The  Transfer  Model) 

(see  also  Part  1,  Section  4.1.3,  The  Transfer  Model) 

4.1  Standard  Module  Names 

SDTS  Topological  Vector  Profile  module  names  (the  unique  name  of  each  individual  module) 
shall  be  standardized,  and  consist  of  four  characters.  All  letters  in  module  names  shall  be 
upper  case.  For  modules  carrying  spatial  objects,  the  module  name  shall  begin  with  the  same 
two  characters  as  the  object  representation  code  for  the  objects  (use  "PC"  for  modules  with 
"PC",  "PX",  and  "PW"  objects  and  use  "FF"  for  composite  objects).  The  other  valid  two 
character  Object  Representation  codes  are  shown  in  Section  2. 1  of  Part  4,  Spatial  Data 
Concepts,  Spatial  Objects.  The  last  two  characters  of  the  module  name  are  free  to  distinguish 
different  modules/files.  Attribute  Primary  and  Secondary  modules  shall  be  named  "Axxx" 
and  "Bxxx"  respectively  (where  x  is  any  number  0-9  or  any  upper  case  letter  A-Z). 

Non-object  modules  shall  be  named  the  same  as  the  primary  module  field  mnemonic  (ISO 
821 1  Tag)  (see  Part  1,  Sections  5.2  and  5.3,  Global  Information  and  Data  Quality  Modules, 
and  Part  3  Table  1): 

IDEN  (Identification), 

CATD  (Catalog/Directory), 

CATX  (Catalog/Cross  Reference), 

CATS  (Catalog/Spatial  Domain), 

SCUR  (Security), 

IREF  (Internal  Spatial  Reference), 

XREF  (External  Spatial  Reference), 

SPDM  (Spatial  Domain), 

DDDF  (Data  Dictionary/Definition), 

DDOM  (Data  Dictionary/Domain), 

DDSH  (Data  Dictionary/Schema), 

ST  AT  (Statistics), 

DQHL  (Data  Quality/Lineage), 

DQPA  (Data  Quality/Positional  Accuracy), 

DQAA  (Data  Quality/Attribute  Accuracy), 

DQLC  (Data  Quality/Logical  Consistency), 

DQCG  (Data  Quality/Completeness) 

More  than  one  module  of  the  following  types  may  exist: 

SCUr,  IREf,  SPDm,  DDDf,  DDOm,  DDSh,  DQH1, 

DQPa,  DQAa,  DQLc,  and  DQCg. 

The  last  character  shall  change  to  reflect  more  than  one  module  of  the  same  type. 
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4.2  Order  of  Records,  Fields,  and  Subfields  within  Modules 

(a)  Records  within  modules  shall  be  ordered,  in  ascending  order,  by  Record  ID. 

But  the  actual  Record  ID  integer  values  need  not  start  with  "1,"  and  records  in 
sequence  may  skip  integers  arbitrarily,  up  to  (2?1  -  1). 

(b)  The  subfields  within  fields  and  fields  within  records  shall  be  ordered  as  in  the 
SDTS  module  specification  layout  tables  in  Part  1,  Section  5. 

4.3  Coordinate  Frame  of  Reference 

(see  also  Part  1,  Section  4. 1.3.5,  Spatial  Registration) 

There  shall  be  only  one  external  coordinate  frame  of  reference  within  a  transfer.  The  external 
spatial  reference  system  shall  be  one  of  the  systems  which  make  up  conformance  level  1: 
latitude-longitude  (geographic).  Universal  Transverse  Mercator/Universal  Polar  Stereographic 
(UTM/UPS),  or  State  Plane  Coordinate  Systems  (SPCS.)  If  different  horizontal  partitions  are 
included  within  the  transfer,  each  may  have  its  own  internal  coordinate  system  (referenced  to 
the  external  spatial  reference  system  by  translation  and  scaling  parameters  in  an  Internal 
Spatial  Reference  module  record). 

4.4  Spatial  Address  (Coordinate)  Format 

(see  also  Part  1,  Section  4. 1.3.5,  Spatial  Registration,  and  Section  5.2.4,  Spatial  Reference) 

4.4.1  External  Spatial  Reference 

Topological  Vector  Profile  transfers  shall  be  restricted  to  the  use  of  conformance  level  1  for 
horizontal  external  coordinates.  To  explicitly  state  this  restriction, 

(a)  the  External  Spatial  Reference  subfield  of  the  Conformance  field  of  the 
Identification  module  shall  have  the  value  of  "1"  indicating  that,  YES,  one  of 
three  recommended  systems  is  used,  and 

(b)  the  Reference  System  Name  subfield  in  the  External  Spatial  Reference  Module 
primary  field  shall  have  the  value  '’GEO”,  "SPCS",  "UTM",  or  "UPS". 

Note  that  Part  1  restricts  the  unit  of  measurement  in  the  external  reference  system  to  meters 
for  all  Z  coordinates  and  X  and  Y  coordinates  when  using  the  State  Plane  Coordinate  System. 
However,  coordinates  can  be  stored  in  the  internal  reference  system  in  feet  as  long  as  the 
appropriate  scaling  factors  are  used  in  the  Internal  Spatial  Reference  module. 


4.4.2  Internal  Representation  of  Spatial  Addresses 

The  internal  representation  of  X,  Y  and  Z  coordinates  shall  be  as  32-bit  signed  implicit  fixed 
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point  binary  numbers  ("BI32"  SDTS  data  type).  Signed  integers  are  represented  in  "two’s 
complement"  format  as  defined  in  ANSI  X3.122  -  1986  Part  3,  Section  5.1,  pages  10-11. 

This  standard  requires  "big-endian"  bit  ordering  in  which  the  most  significant  bit  is  stored 
first  (see  also  ISO  8632-3,  and  SDTS  Part  3,  Section  9.3,  Binary  Data.) 

Internal  fixed  point  coordinates  can  be  converted  to  external  coordinates  by  converting  to 
floating  point  and  applying  the  scaling  and  translation  values  from  an  Internal  Spatial 
Reference  module— see  Part  1,  5.2.4. 1.) 

4.4.3  Restrictions  on  X  and  Y  Subfields 

The  X  subfield  of  spatial  addresses  shall  only  be  used  to  transfer  longitude  and  easting 
values.  The  Y  subfield  shall  only  be  used  to  transfer  latitude  or  northing. 

4.5  Null  (and  Like)  Values 

(see  also  Part  1,  Section  4. 1.3. 3.9,  Nulls  and  Defaults) 

When  a  transfer  uses  fixed  length  subfields  (e.g.  to  carry  attribute  data  linked  to  the  various 
objects),  then  special  consideration  must  be  given  to  handling  Null  values.  The  SDTS  default 
option  for  implementing  nulls  is  not  feasible  in  this  case.  When  appropriate,  the  following 
text  shall  be  encoded  in  the  Comment  subfield  of  a  Logical  Consistency  module  record,  and 
implemented: 

When  a  subfield,  either  user-defined  in  Attribute  Primary  and  Attribute  Secondary 
module  records,  or  in  other  SDTS  module  records,  is  implemented  as  fixed-length,  the 
following  null  scheme  is  used:  (a)  when  information  to  be  encoded  in  the  subfield  is 
known  to  be  not  applicable  (undefined,  not  relevant),  then  the  subfield  is  valued  by  a 
string  of  spaces;  and  (b)  when  the  information  to  be  encoded  is  relevant  but  unknown 
(or  missing),  then  the  subfield  is  valued  by  a  string  of  question  marks  "?". 

The  Logical  Consistency  module  with  the  above  text  shall  be  associated  to  applicable 
modules  through  the  Catalog/Cross  Reference  module. 

4.6  Attribute  Usage 

(see  also  Part  1,  Annex  B  Section  B.6  Suggested  Code  Sets) 

All  agencies  shall  use  established  FIPS  codes  where  applicable,  such  as  FIPS  PUB  6-4  (31 
August  1990)  Counties  and  Equivalent  Entities  Codes  or  FIPS  PUB  10-3  (9  February  1984) 
Countries,  Dependencies,  Areas  of  Special  Sovereignty  and  their  Principal  Administrative 
Division. 
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4.7  Relationships  Between  Modules  and  2-D  Manifolds 

(a)  For  objects  particular  to  one  2-D  manifold  there  shall  be: 

exactly  one  Point-Node  module  for  required  simple  object  type  NO; 

exactly  one  Line  module  for  required  simple  object  type  LE; 

exactly  one  Polygon  module  for  simple  object  types  PC,  PW,  and  PX; 

zero  or  one  Point-Node  module  for  optional  simple  object  type  NE; 

zero  or  one  Point-Node  module  for  opdonal  simple  object  type  NA; 

and  zero  or  one  Point-Node  module  for  optional  simple  object  type  NL. 

There  is  no  restriction  on  the  number  of  modules  containing  points  with  the  NP 
object  representation  code. 

(b)  If  more  than  one  2-D  manifold  is  transferred,  data  particular  to  a  given  2-D 
manifold  will  be  transferred  within  its  own  set  of  simple  object  modules,  and 
these  modules  will  be  related  to  each  other  and  to  theme(s)  and  partition  (map 
or  domain)  in  the  Catalog/Spatial  Domain  module.  If  more  than  one  2-D 
manifold  is  contained  in  a  transfer,  each  2-D  manifold  shall  be  assigned  a 
unique  name  which  shall  be  used  in  the  Aggregate  Object  subfield  for  all 
records  for  modules  which  apply  only  to  the  particular  2-D  manifold. 

(c)  Each  partition  may  have  its  own  internal  coordinate  system.  Therefore  an 
SDTS  transfer  with  more  than  one  partition  (and  2-D  manifolds)  may  have 
more  than  one  Internal  Spatial  Reference  module.  But  separate  2-D  manifolds 
representing  different  layers  of  the  same  partition  shall  share  the  same  Internal 
Spatial  Reference  module. 

(d)  There  may  be  different  entity  types  represented  by  the  records  of  a  given  object 
module  (e.g.  a  single  Composite  module  may  contain  records  for  many 
different  types  of  entities). 

(e)  There  are  two  methods  of  identifying  the  entity  type  of  a  particular  spatial 
object;  (1)  the  SDTS  default  option  which  uses  the  Data  Dictionary/Schema 
module  to  assign  an  entity  to  a  particular  attribute  in  a  Attribute  Primary 
module  or  (2)  the  method  described  under  Section  4.9  of  Part  4.  When  the 
SDTS  default  option  is  used,  each  different  entity  type  shall  be  distinguished  in 
its  own  unique  Attribute  Primary  module.  When  using  the  SDTS  default 
option,  there  shall  be  one  Attribute  Primary  module  for  each  unique  entity  type 
for  data  particular  to  a  given  2-D  manifold. 
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(f)  Composite  objects  may  be  composed  of  objects  from  more  than  one  2-D  mani¬ 
fold.  Additional  Composite  modules  shall  be  used  to  transfer  such  composite 
objects.  There  shall  be  a  separate  Attribute  Primary  module  for  each  entity 
type  represented  in  these  multi-manifold  Composite  modules. 

4.8  Multi-valued  Attributes 

Attributes  that  can  be  multi-valued  shall  be  in  their  own  tables,  along  with  any  other 
attributes  that  are  functionally  dependent.  An  attribute’s  cardinality  and  functional 
dependence  is  solely  determined  by  the  data  encoder’s  data  model.  As  an  example  of  multi¬ 
valued  consider  an  entity  "road"  with  the  attribute  "name"  that  has  the  two  values  "10th 
Street"  and  "Highway  BB".  Attributes  are  functionally  dependent  when  the  value  of  one 
attribute  determines  the  value  of  another  attribute.  For  example,  say  attribute  "route_number" 
is  dependent  on  "name",  which  means  the  value  of  "name"  determines  the  value  for 
"route_number".  (See  Annex  B  for  an  example  of  encoding  multi-valued  attributes.) 

4.9  Attributing  Feature  Objects  with  Entity  Labels 

The  SDTS  implementation  of  the  entity-attribute-attribute  value  feature  model  provides  a 
means  of  directly  assigning  attribute  values  to  specific  feature  objects.  The  type  of  entity 
which  the  object  represents  is  specified  indirectly  through  Data  Dictionary/Schema  module 
records.  The  assumption  is  that  each  entity  type  represented  is  characterized  by  attributes.  In 
some  cases,  however,  all  that  may  be  encoded  about  a  feature  is  its  entity  type  with  no  other 
attributes. 

For  use  with  features  with  entity  labels  but  no  attributes  (and  optionally  in  cases  where 
different  features  share  the  same  attributes),  two  generic  attribute  labels  are  defined  by  this 
profile:  "ENTITYJLABEL"  and  "ENTITY_AUTHORITY"  (an  entity  label  may  only  be 
unique  when  coupled  with  the  authority  for  its  definition).  The  authority  for  the  definition  of 
these  two  attribute  labels  is  this  profile,  designated  in  Data  Dictionary/Schema  records 
(Attribute  Authority  subfield)  as  "SDTS/TVP".  (No  Data  Dictionary/Definition  or  Data 
Dictionary/Domain  records  are  necessary  for  these  two  attribute  labels.)  The  domain  of 
attribute  values  for  these  attributes  shall  be  any  entity  label  and  its  authority  as  defined  in 
either  SDTS  Part  2  or  Data  Dictionary /Definition  records  included  with  the  transfer  (either 
internally  or  externally).  When  all  entity  labels  in  a  single  transfer  are  defined  by  the  same 
authority,  the  ENTITY_AUTHORITY  attribute  may  be  omitted  in  the  attribute  records. 

Annex  C  contains  an  example  of  attributing  feature  objects  with  entity  labels. 
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5  Transfer  Module  Specification 

(see  also  Part  1,  Section  5,  Transfer  Module  Specification) 

This  section  addresses  the  module  level  restrictions  as  they  apply  to  a  transfer.  Certain 
requirements  of  Part  1  are  repeated  here  for  clarity.  Following  the  module  level  restric¬ 
tions/requirements,  any  restrictions  on  field/subfield  values  are  noted  for  each  module.  The 
order  of  coverage  follows  that  of  Part  1,  Section  5. 

The  following  table  contains  the  inclusion/exclusion,  and  cardinality  rules  for  each  module. 
The  standardized  modules  names  are  included,  along  with  the  minimum  number  and  the 
maximum  number  of  occurrences  of  the  module  type.  A  lowercase  "n"  indicates  that  the 
upper  limit  is  user  defined.  Any  lowercase  letters  or  dots  in  the  module  name  has  the 
meaning  explained  in  Section  4,  Standard  Module  Names. 


Module  Type 

Name 

Min.  No. 

Max.  No. 

Global  Information  Modules  (see  also  Part  1,  Section  5.2,  Global  Information  Modules) 

Identification 

IDEN 

1 

1 

Catalog/Directory 

CATD 

1 

1 

Catalog/Cross  Reference 

CATX 

0 

1 

Catalog/Spatial  Domain 

CATS 

1 

1 

Security 

SCUr 

0 

n 

Internal  Spatial  Reference 

IREf 

1 

n 

External  Spatial  Reference 

XREF 

1 

1 

Registration 

-- 

0 

0 

Spatial  Domain 

SPDm 

0 

n 

Data  Dictionary/Definition 

DDDf 

O5 

n6 

Data  Dictionary/Domain 

DDOm 

l7 

n6 

Data  Dictionary/Schema 

DDSh 

1 

n6 

Transfer  Statistics 

STAT 

1 

1 

5A  minimum  of  one  module  is  required  if  the  transfer  does  not  have  level  1  feature  conformance  with 
SDTS  Part  2.  The  module  may  be  contained  in  an  external  SDTS  data  dictionary  as  described  in  Annex  A. 

6A  maximum  of  one  module  is  recommended. 

7The  module  may  be  contained  in  an  external  SDTS  data  dictionary  as  described  in  Annex  A. 
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Module  Type 

Name 

Min  No. 

Max.  No. 

Data  Quality  Modules  (see  also  Part  1,  Section  5.3,  Data  Quality  Modules) 

Lineage 

DQH1 

1 

n 

Positional  Accuracy 

DQPa 

1 

n 

Attribute  Accuracy 

DQAa 

1 

n 

Logical  Consistency 

DQLc 

1 

n 

Completeness 

DQCg 

1 

n 

Composite  Module 

FF.. 

0 

n 

Attribute  Modules  (see  also  Part  1,  Section  5.4,  Attribute  Modules) 

Attribute  Primary 

A... 

1 

n 

Attribute  Secondary 

B... 

0 

n 

Vector  Modules  (see  also  Part  1,  Section  5.6,  Vector  Modules) 

Point-Node 

NO.. 

1 

n 

NE.„  NA.„  NL.„ 
NP.. 

0 

n 

Line 

LE.. 

1 

n 

Arc8 

- 

0 

0 

Ring9 

- 

0 

0 

Polygon 

PC.. 

1 

n 

Raster  Modules 

- 

0 

0 

Graphic  Representation  Modules10 

- 

0 

0 

5.1  Global  Information  Modules 

(see  also  Part  1,  Section  5.2,  Global  Information  Modules) 

(a)  If  more  than  one  2-D  manifold  is  transferred,  data  particular  to  a  given  2-D 
manifold  will  be  transferred  within  their  own  set  of  modules.  These  modules 
will  be  related  to  each  other  and  to  theme(s)  and  partition  (map  or  domain)  in 
the  Catalog/Spatial  Domain  module.  If  more  than  one  2-D  manifold  is 
contained  in  a  transfer,  each  2-D  manifold  shall  be  assigned  a  unique  name 
which  shall  be  used  in  the  Aggregate  Object  subfield  for  all  records  which 


aAllowed  only  as  an  option  as  described  in  Annex  D. 
’Allowed  only  as  an  option  as  described  in  Annex  E. 
l0Allowed  only  as  an  option  as  described  in  Annex  F. 
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apply  only  to  the  particular  2-D  manifold. 

(b)  Each  partition  may  have  its  own  internal  coordinate  system.  Therefore  an 
SDTS  transfer  with  more  than  one  partition  (and  2-D  manifolds)  may  have 
more  than  one  Internal  Spatial  Reference  module.  But  separate  2-D  manifolds 
representing  different  layers  of  the  same  partition  shall  share  the  same  Internal 
Spatial  Reference  module. 

(c)  For  each  SDTS  transfer  data  set  that  does  not  reference  an  external  SDTS  data 
dictionary,  there  must  be  at  least  one  and  it  is  recommended  that  there  be  only 
one  of  the  following  global  module: 

Data  Dictionary/Domain  (DDOM). 

For  each  SDTS  transfer  data  set  that  does  not  reference  an  external  SDTS  data 
dictionary  and  that  does  not  have  level  1  feature  conformance  with  Part  2,  there 
must  be  at  least  one  and  it  is  recommended  that  there  be  only  one  of  the 
following  global  module: 

Data  Dictionary/Definition  (DDDF). 

There  must  be  at  least  one  and  it  is  recommended  that  there  be  only  one  of  the 
following  global  module: 

Data  Dictionary/Schema  (DDSH). 

(d)  A  common  set  of  Data  Dictionary/Definition  and  Data  Dictionary/Domain 
modules  may  be  used  for  an  entire  series  of  files  to  be  distributed.  This  Data 
Dictionary  may  be  made  available  separately;  and  it  need  not  be  duplicated 
within  each  SDTS  transfer.  If  the  SDTS  data  dictionary  is  separate  from  the 
individual  SDTS  transfer  data  set,  then  it  shall  be  uniquely  identified  and 
referenced  by  the  individual  SDTS  transfer  data  set.  Annex  A  describes  the 
method  by  which  such  a  master  data  dictionary  transfer  will  be  accomplished. 
See  also  Part  1,  Section  4. 1.3. 3.1,  Modules  within  a  Spatial  Data  Transfer 
(clause  (d)),  and  Section  5.2.2. 1,  Catalog/Directory  (Table  11,  subfields 
External  and  Module  Version),  and  Section  5.2.6  Data  Dictionary. 
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5.2  Data  Quality  Modules 

(see  also  Part  1,  Section  5.3,  Data  Quality  Modules) 

(a)  A  common  set  of  Data  Quality  modules  may  be  used  for  an  entire  series  of 
files  to  be  distributed.  These  Data  Quality  modules  may  be  made  available 
separately;  and  they  need  not  be  duplicated  within  each  SDTS  transfer.  If  the 
SDTS  Data  Quality  modules  are  separate  from  the  individual  SDTS  transfer 
data  set,  then  they  shall  be  uniquely  identified  and  referenced  by  the  individual 
SDTS  transfer  data  set.  See  Part  1,  Section  4. 1.3. 3.1,  Modules  within  a  Spatial 
Data  Transfer  (clause  (e)),  and  Section  5.2.2. 1,  Catalog/Directory  (Table  11, 
subfields  External  and  Module  Version). 

(b)  Separate  processing  histories  pertaining  to,  for  example,  separate  data  layers, 
shall  be  documented  in  a  Lineage  module. 

(c)  If  data  are  collected  from  a  graphic  map,  the  Positional  Accuracy  module  shall 
contain  a  statement  explaining  that  the  data  may  contain  cartographic  offsets. 

(d)  The  technique  used  to  verify  topology  shall  be  documented  in  the  Logical 
Consistency  module. 

(e)  Completeness  modules  and  (or)  Logical  Consistency  modules  shall  be  used  to 
report  and  explain  data  encoding  practices,  especially  in  object  records,  which 
might  seem  contrary  to,  or  to  deviate  from,  normal,  standard  or  preferred 
practices.  For  example,  if  one  or  more  composite  object  record  lacks  lists  of 
component  objects,  the  meaning  of  this  shall  be  explained  in  a  Completeness 
module. 

5.3  Attribute  Modules 

(see  also  Part  1,  Section  5.4,  Attribute  Modules) 

There  is  no  restriction  on  the  relationships  between  objects  and  Attribute  Primary  module 
records:  the  relationship  may  be  one-to-one,  one-to-many,  many-to-one,  or  many-to-many.  If 
the  relationship  is  not  one-to-one  or  one-to-many,  the  encoder  is  required  to  alert  decoders  to 
this  fact  in  the  Catalog/Cross  Reference  module  record  for  the  modules  involved.  This  shall 
be  done  by  placing  the  characters  "JJ"  into  the  first  two  characters  of  the  Comment  subfield. 

5.4  Composite  Module 

(see  also  Part  1,  Section  5.5,  Composite  Module) 

(a)  Composite  objects  may  optionally  not  have  a  list  of  component  objects.  If 
such  a  list  does  not  exist,  the  meaning  of  this  shall  be  explained  in  a  Data 
Quality  Completeness  module  record. 
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(b)  Chains  comprising  a  continuous  linear  composite  object  may  be  ordered.  Each 
Chain  ID  in  the  list  of  components  may  have  an  "F"  (for  forward)  or  "B"  (for 
backward)  in  the  Foreign  ID  Usage  Modifier  subfield  (see  Part  I,  Section  5.1.2, 
Foreign  Identifiers).  The  list  of  chain  Foreign  IDs  may  be  ordered  such  that: 
the  first  point  (start  node  of  "F"  chains  and  end  node  of  "B"  chains)  of  each 
chain  following  the  first  in  the  list,  shall  be  equivalent  to  the  last  point  (end 
node  of  "F"  chains  and  start  node  of  "B"  chains)  of  the  previous  chain  in  the 
list. 

The  ordering  and  forward/backward  chain  usage  modifiers  are  included  to 
allow  the  transfer  of  directional  information  for  composite  objects  representing 
such  things  as  one-way  roads  and  drains.  This  capability  to  direct  and 
sequence  chains  could  also  be  used  to  specify  plotting  sequences,  but  that  is 
not  a  major  reason  for  including  this  capability  in  this  Topological  Vector 
Profile. 

5.5  Vector  Modules 

(see  also  Part  1,  Section  5.6,  Vector  Modules) 

5.5.1  Topological  Pointers 

(a)  Nodes  shall  not  have  any  topological  pointers; 

(b)  complete  chains  shall  have  start  node,  end  node,  polygon  right,  and  polygon 
left  pointers  (polygon  pointers  shall  be  to  GT-polygon  records); 

(c)  entity  points  and  area  points,  if  present,  shall  have  pointers  to  their  surrounding 
GT-polygon  (only  one;  entity  points  may  not  exist  at  the  same  location  as  a 
chain  or  node  which  is  part  of  the  same  2-D  manifold); 

(d)  label  points  may  optionally  have  pointers  to  their  surrounding  GT-polygon; 

(e)  points  with  the  "NP"  object  representation  code  shall  not  have  topological 
pointers; 

(f)  GT-polygons  may  optionally  have  pointers  to  their  chains,  in  "walk-around" 
sequence;  Pointers  to  chains  (if  present)  will  also  have  an  "L"  (for  polygon  on 
left  side  of  chain)  or  an  "R"  (for  polygon  on  right  side  of  chain)  in  the  Foreign 
ID  Usage  Modifier  subfield  (see  Part  1,  Section  5.1.2,  Foreign  Identifiers). 

The  information  in  the  Data  Structure  subfield  of  the  Identification  module  will  indicate  the 
presence  or  absence  of  the  various  optional  items  such  as  area  points  and  pointers  from 
polygons  to  chains.  The  presence  of  these  items  in  a  transfer  will  typically  reflect  their 
presence  in  the  source  format  and  structure.  For  example,  Standard  DLG  data  do  not  have 
polygon-to-chain  pointers,  so  a  transfer  from  DLG-S  data  would  not  have  pointers  from 
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polygons  to  chains  (unless  these  pointers  were  built  and  added  by  the  SDTS  encoder,  which  is 
doubtful). 

5.5.2  Universe  Polygon 

(see  Part  1  definition  2. 3. 3. 3.1) 

A  universe  polygon  (object  representation  code  "PW")  is  mandatory.  Its  Record  ID  subfield 
shall  be  encoded  with  "  1 ".  Attributes  of  the  universe  polygon,  if  any,  shall  have  null  values 
(see  below  for  specifications  for  implementing  null  values). 

The  Ring  ID  field  is  not  permitted  for  universe  polygons  with  an  object  representation  code 
of  "PW". 

5.5.3  Void  Polygons 

(see  Part  1  definition  2.3. 3. 3. 2) 

Other  GT-polygons  may  be  included  with  attribution  similar  to  the  universe  polygon;  these 
void  polygons  shall  be  coded  with  a  "PX"  object  representation  code. 

The  Ring  ID  field  is  not  permitted  for  void  polygons  with  an  object  representation  code  of 
"PX". 


5.5.4  Attribute  Primary  References 

Object  records  may  reference  zero,  one  or  more  attribute  primary  records  except  for  area 
points  ("NA"  object  representation  code)  which  shall  always  reference  zero  attribute  primary 
records.  Attribute  primary  references  for  area  points  should  instead  be  contained  in  the 
surrounding  GT-polygon  spatial  object  record. 

5.5.5  Number  of  Object  Types  Within  a  Single  Module 

A  single  module  shall  contain  only  records  of  a  single  object  type  (indicated  by  appropriate 
object  representation  code),  with  the  technical  exception  that  modules  carrying  "PC"  (GT- 
polygon)  records  may  also  contain  a  "PW"  (universe  polygon)  and  "PX"  (void  polygon) 
records. 

5.5.6  Use  of  "NP"  Points 

Points  with  the  "NP"  object  representation  code  are  allowed  only  for  use  in  data  quality 
reports.  An  example  use  is  to  transfer  control  points  used  for  transformations  which  might  be 
part  of  the  Lineage  Data  Quality  report. 

5.5.7  Label  Points 

The  Attribute  Primary  Foreign  ID  (PAID)  field  is  mandatory  for  the  "NL"  object 
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representation  code.  This  field  references  the  record  and  the  label  of  the  attribute  to  be 
annotated.  This  field  shall  reference  an  attribute  record  in  either  an  Attribute  Primary  module 
or  an  Attribute  Secondary  module. 

5.6  Raster  Modules 

These  modules  shall  not  be  included  in  a  transfer  conforming  to  this  profile. 

5.7  Graphic  Representation  Modules 

These  modules  shall  not  be  included  in  a  transfer  conforming  to  this  profile  unless  the  options 
described  in  Annex  F  are  implemented.  Encoders  and  decoders  are  not  required  to  support 
these  module  types  to  be  conforming  to  this  profile. 

5.8  Module  Restrictions/Requirements:  Identification  Module 

(see  also  Part  1,  Section  5.2.1,  Table  10  Identification) 

5.8.1  External  Spatial  Reference 

(see  also  Part  1,  Section  5. 2. 1.2. 2,  External  Spatial  Reference  Subfield) 

The  External  Spatial  Reference  subfield  of  the  Conformance  field  of  the  Identification  module 
shall  have  the  value  of  "1"  indicating  that,  YES,  one  of  three  recommended  systems  is  used. 

5.8.2  Profile  Identification 

Each  transfer  encoded  per  these  specifications  shall  have 

"SDTS  TOPOLOGICAL  VECTOR  PROFILE" 

as  the  value  of  the  Profile  Identification  subfield  of  the  Identification  module  primary  field. 

If  options  described  in  Annexes  D,  E,  or  F  are  implemented  in  a  transfer,  each  implemented 
annex  shall  be  indicated  by  adding  a  and  the  upper  case  letter  of  the  annex  to  the  Profile 
Identification  subfield.  Any  combination  of  annexes  may  be  implemented  in  a  transfer.  For 
example,  if  a  transfer  implements  Annexes  D  and  E,  Profile  Identification  would  contain 
"SDTS  TOPOLOGICAL  VECTOR  PROFILE/D/E". 

Each  transfer  shall  have 

"VERSION  1.0  JUNE  10,  1994" 

as  the  value  of  the  Profile  Version  subfield  of  the  Identification  module  primary  field. 

Each  transfer  shall  have 
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as  the  value  of  the  Profile  Document  Reference  subfield  of  the  Identification  module  primary 
field. 


5.8.3  Feature  Level  Conformance 

(see  also  Part  1,  Section  5. 2. 1.2. 3,  Features  Level  Subfield) 

Any  level  of  SDTS  Features  Conformance  is  allowed  (the  value  in  the  Features  Level  subfield 
of  the  Conformance  field  of  the  Identification  module  record  shall  be  either  "1",  "2",  "3"  or 
"4").  Note  that  if  SDTS  is  not  the  authority  for  any  entity  and  attribute  terms,  then  the 
Features  Level  subfield  must  be  valued  as  "4". 

5.8.4  Global  Attributes 

The  Attribute  ID  field  is  used  to  reference  global  information  that  applies  to  the  entire 
transfer  (e.g.  Census  TIGER/LINE  min  and  max  ID  numbers). 

5.9  Module  Restrictions/Requirements:  Internal  Spatial  Reference 

The  X  subfield  of  spatial  addresses  shall  be  used  only  for  longitude  and  easting  values.  The 
Y  subfield  shall  be  used  only  for  latitude  and  northing.  Therefore,  the  Spatial  Address  X 
Component  Label  subfield  is  restricted  to  "LONGITUDE"  when  the  external  spatial  reference 
system  is  geographic  and  "EASTING"  when  the  external  spatial  reference  system  is 
UTM/UPS  or  SPCS.  The  Spatial  Address  Y  Component  Label  subfield  is  restricted  to 
"LATITUDE"  when  the  external  spatial  reference  system  is  geographic  and  "NORTHING" 
when  the  external  spatial  reference  system  is  UTM/UPS  or  SPCS. 

The  Scale  Factor  X,  Scale  Factor  Y,  X  Origin,  and  Y  Origin  subfields  in  the  Internal  Spatial 
Reference  field  are  required.  If  spatial  addresses  include  Z  values,  the  Scale  Factor  Z  and  Z 
Origin  subfields  are  required.  These  subfields  specify  the  scaling  and  translation  required  to 
transform  spatial  addresses  from  the  internal  spatial  reference  to  the  external  spatial  reference 
(see  Part  1,  5.2.4. 1).  The  use  of  the  Registration  module  to  specify  this  transformation  is  not 
allowed. 

5.10  Module  Restrictions/Requirements:  External  Spatial  Reference 

The  Reference  System  Name  subfield  in  the  External  Spatial  Reference  Module  primary  field 
shall  have  the  value  "GEO",  "SPCS",  "UTM",  or  "UPS"  depending  upon  the  external  spatial 
reference  system  being  used. 

5.11  Module  Restrictions/Requirements:  Catalog/Spatial  Domain 

The  following  requirements  apply  to  the  Catalog/Spatial  Domain  field  in  the  Catalog/Spatial 
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Domain  module: 


(a)  Either  the  Domain  or  Map  subfields  or  both  are  required  so  that  the  coverage 
of  the  module  is  indicated. 

(b)  The  Theme  subfield  is  required  for  all  data  sources  which  separate  data  into 
themes. 

(c)  The  Aggregate  Object  Type  subfield  shall  contain  the  object  representation 
code  "GT"  indicating  that  the  module  references  a  2-D  manifold. 

(d)  The  Aggregate  Object  subfield  shall  be  used  to  indicate  the  2-D  manifold  to 
which  modules,  themes,  domains,  and  maps  are  related.  If  more  than  one  2-D 
manifold  is  contained  in  a  transfer,  each  2-D  manifold  shall  be  assigned  a 
unique  name  which  shall  be  used  in  the  Aggregate  Object  subfield  for  all 
records  for  modules  which  apply  only  to  the  particular  2-D  manifold.  The  use 
of  the  Aggregate  Object  subfield  is  optional  in  other  cases. 

5.12  Module  Restrictions/Requirements:  Catalog/Directory 

So  that  the  contents  of  a  transfer  are  independent  of  the  transfer  media,  the  following 
restrictions  are  placed  on  the  primary  field  of  the  Catalog/Directory  module: 

(a)  The  Volume  subfield  shall  not  be  used. 

(b)  The  File  subfield  shall  not  include  a  directory  path,  only  a  file  name  meeting 
the  requirements  of  Section  6.5. 

5.13  Module  Restrictions/Requirements:  Data  Dictionary/Schema 

The  Entity  Authority  and  Attribute  Authority  subfields  shall  contain  "SDTS-USA"  when  Part 
2  of  FIPS  173  is  the  authority  for  the  definition.  When  a  standard  register  of  entities  and 
attributes  of  a  country  other  than  the  United  States  is  the  authority,  these  subfields  shall 
contain  "SDTS-"  followed  by  the  three-character  ISO  3166  country  code.  Entity  Authority 
and  Attribute  Authority  may  have  a  maximum  length  of  8  graphics  characters. 


5.14  Module  Restrictions/Requirements:  Data  Dictionary/Domain 

The  Attribute  Authority  subfield  may  have  a  maximum  length  of  8  graphics  characters. 

5.15  Module  Restrictions/Requirements:  Data  Dictionary/Definition 

The  Attribute  Authority  subfield  may  have  a  maximum  length  of  8  graphics  characters. 
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6  ISO  8211  Specific  Decisions 

(see  also  ANSI/ISO  8211-1985  a.k.a.  FIPS  PUB  123  Specifications  for  a  Data  Descriptive 

File  for  Information  Interchange,  and  Part  3,  ISO  8211  Encoding) 

6.1  Objective 

(see  also  Part  3,  Sections  1.1  and  1.2,  Purpose  and  Objectives): 

SDTS/ISO  8211  is  optimized  for  retrieval  and  storage  (versus  interactive  decoding);  non- 

SDTS  directories/indices  may  be  added  to  allow  such  interactive  decoding  (e.g.  on  a  CD- 

ROM  media). 

6.2  Relationship  of  Modules  to  ISO  8211  Files 

(see  also  Part  1,  Section  4.1.3,  Tables  3a  &  3b, 

and  Part  3,  Section  7,  Assignment  of  Fields  to  Records  and  Files) 

(a)  A  file  (an  ISO  8211  Data  Definition  File  (DDF))  shall  contain  one  and  only 
one  module.  All  Topological  Vector  Profile  files  must  have  only  fields  from 
the  same  module  in  any  particular  record  and  file,  i.e.  each  file  will  represent 
only  a  single  module.  Normally,  a  module  will  only  occupy  a  single  file. 

(b)  A  module  may  span  files  only  when  the  size  of  a  single  file  would  exceed 
volume  capacity,  that  is  if  the  file  needs  to  be  broken  into  separate  files  to  be 
placed  on  separate  volumes,  because  of  media  constraints.  Thus  modules  may 
be  broken  into  different  files  only  in  a  multi-volume  transfer,  and  then  only  if 
the  module  cannot  itself  fit  on  a  single  volume. 


6.3  Media 

(see  also  Part  3,  Section  10,  Media  Requirements) 

When  only  a  single  SDTS  transfer  is  on  a  media  volume,  then  the  volume  name  shall  begin 
with  the  same  four  characters  as  the  first  four  characters  of  file  names  for  that  transfer  (see 
section  6.5.)  When  multiple  transfers  are  contained  on  a  volume,  then  the  first  four 
characters  of  the  volume  name  shall  be  "SDTS". 

For  multi-volume  transfers,  the  first  four  characters  shall  be  the  transfer  base  characters  as 
described  above,  and  the  remainder  of  the  name  shall  indicate  the  volume  sequence. 

6.4  Organization  of  Files  on  Media 

In  general,  the  files  comprising  a  single  transfer  shall  be  kept  separate  from  any  other  transfer 
files. 


(a)  On  floppy  disks  and  CD-ROM,  each  transfer  shall  be  grouped  completely  in  a 
single  directory.  Multiple  transfers  may  reside  on  the  same  media  volume. 
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with  each  in  its  own  subdirectory. 

(b)  On  magnetic  tape,  files  of  a  single  transfer  shall  be  ordered  by  module  type, 
following  the  order  of  presentation  in  Part  1,  Section  5.  File  adjacency  shall  be 
used  to  group  transfer  files  when  multiple  transfers  reside  on  the  same  media 
volume.  All  files  that  follow  the  Identification  Module  (first  file  of  a  transfer) 
up  until  another  Identification  Module  or  an  end  of  tape  marker  is  encountered 
shall  be  considered  part  of  the  transfer. 

(c)  A  file  called  "README"  is  required  (see  Part  3,  Section  11,  Conformance). 
There  shall  be  one  such  file  per  media  volume.  This  file  shall  reside  in  the 
root  directory  of  a  floppy  disk  or  CD-ROM. On  a  magnetic  tape,  the  README 
file  shall  be  located  immediately  before  the  Identification  module  (the  first  file 
in  each  SDTS  transfer)  of  the  first  SDTS  transfer.  It  is  permissible  for  non- 
SDTS  adjunct  files  to  be  placed  before  the  README  file.  Contents  of  the 
README  file  is  discussed  in  section  6.10. 

6.5  File  Names 

SDTS  Topological  Vector  Profile  file  names,  to  be  consistent  from  the  various  agencies  shall 
consist  of  eight  characters  of  base  name.  A  single  transfer  data  set  shall  use  the  same  first 
four  characters  in  the  file  name  of  each  SDTS  ISO  8211  file  in  the  entire  transfer.  The  next 
four  characters  in  the  file  name  shall  be  the  unique  name  of  the  module  transferred  in  that  file 
(see  naming  convention  for  modules  in  Section  4.1  of  Part  4).  When  allowed,  the  extension 
should  be  ".DDF"  to  indicate  the  type  of  file  transferred;  but  the  last  character  of  this 
extension  or  an  optional  ninth  character  on  the  base  name  may  be  used  in  the  case  of  modules 
that  span  files.  Thus  the  extension  could  become  ".DDG",  ".DDH",  ".DDI",  ...  for  multi¬ 
volume  modules.  Such  file  extenders  are  optional.  Any  file  that  is  not  ISO  8211  compliant 
(e.g.  adjunct  files)  shall  not  have  the  ".DDx"  extension.  All  letters  in  file  names  shall  be 
upper  case. 

6.6  Taking  Advantage  of  Dropped  Leader  and  Directory 

(see  also  Part  3,  Section  6.4,  Repeating  Fields  and  Records) 

This  profile  encourages  taking  advantage  of  ISO  8211  mechanisms  to  reduce  file  size.  All 
modules  shall  use  fixed  size  fields  whenever  practical  to  allow  for  the  dropping  of  leader  and 
directory  information  from  the  data  records  in  ISO  8211.  In  the  case  where  there  are  a  few 
records  that  exceed  the  fixed  size  fields’  size,  records  shall  be  ordered  within  a  file  to 
maximize  the  use  of  dropped  leaders  and  directories.  This  means  that  exceptional  data  records 
(DRs)  shall  be  placed  first  in  the  DDF.  All  records  that  can  share  a  common  leader  and 
directory  shall  be  grouped  at  the  end  of  the  file.  (This  is  necessary  because  once  the  leader 
and  directory  are  dropped,  they  cannot  be  respecified  later  in  the  file.) 

Maximizing  the  use  of  dropped  leaders  and  directories  needs  to  be  taken  into  consideration 
when  designing  attribute  modules.  If  there  are  attributes  that  can  have  a  wide  range  in  the 
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size  of  their  value  (e.g.  place  names),  then  considering  separating  these  attributes  into  their 
own  module. 

6.7  ISO  8211  DDR  Contents 

(a)  Data  descriptive  fields  which  have  no  specified  labels  may  be  augmented  by 
user-supplied  labels  for  the  identification  of  subfield  data.  An  import  system  is 
not  required  to  recognize  user-supplied  labels. 

(b)  Subfield  labels  for  the  horizontal  components  of  spatial  address  fields  shall  be 
"X"  and  'T. 

(c)  The  first  part  of  the  file  title  shall  be  consistent  for  all  files  within  the  transfer, 
but  the  last  part  should  be  unique  for  each  file  and  give  some  indication  of  the 
contents  of  that  file.  This  file  title  should  be  equivalent  to  the  eight  character 
base  name  (plus  the  optional  ninth  character). 

6.8  Use  of  Binary  Data  Type  for  Spatial  Addresses 

A  binary  data  type  shall  be  used  in  the  subfields  of  a  spatial  address  field.  The  binary 
subfields  shall  be  a  fixed  width  of  32  bits. 

(a)  In  the  case  where  the  spatial  address  field  does  not  repeat,  the  following  format 
control  shall  be  used  for  a  spatial  address  type: 

(2B(32)) 

where  2  =  2  or  3  depending  on  x,y  or  x,y,z 
B  =  indicates  binary  type  subfield 
32  =  specifies  the  width  of  the  binary  subfield 

(b)  In  the  case  where  all  Data  Records  (DR)  in  a  DDF  contain  the  same  number  of 
repetitions,  a  user-calculated  repeat  factor  shall  be  used  in  the  format  control 
for  the  field.  A  format  control  for  a  spatial  address  type  field  shall  have  the 
form: 

(n(2B(32))) 

where  n  =  the  number  of  spatial  address  tuples 
2  =  2  or  3  depending  on  x,y  or  x,y,z 
B  =  indicates  binary  type  subfield 
32  =  specifies  the  width  of  the  binary  subfield 

(c)  In  the  case  where  each  DR  in  a  DDF  contains  a  different  number  of  repetitions 
(such  as  is  likely  to  occur  in  the  Line  module),  the  following  format  control 
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shall  be  used: 


((2B(32))) 

where  2  =  2  or  3  depending  on  x,y  or  x,y,z 
B  =  indicates  binary  type  subfield 
32  =  specifies  the  width  of  the  binary  subfield 

ISO  8211  does  not  permit  a  binary  field  located  after  the  left  parenthesis  to 
implicitly  repeat.  Therefore,  the  above  format  includes  an  additional  pair  of 
parentheses. 

6.9  Use  of  Character  Data  Type  for  Dates 

(see  also  Part  3,  Section  9.2,  Dates) 

Dates  in  the  form  YYYYMMDD  are  to  be  encoded  as  ISO  8211  data  type  =  A. 

6.10  README  File 

(see  also  Part  3,  Section  11,  Conformance) 

The  README  file  shall  contain  volume  name,  date,  a  list  of  SDTS  transfers  (if  more  than 
one),  and  then  for  each  SDTS  transfer:  a  list  of  subdirectories  and  non-SDTS  files,  if 
appropriate,  the  file  name  of  the  Catalog/Directory  module,  where  it  can  be  found,  and  an 
explanation  that  this  file  and  all  other  SDTS  files  are  in  ISO  8211  format,  and  that  the 
Catalog/Directory  module  carries  a  complete  directory  to  all  other  SDTS  ISO  8211  files 
comprising  the  SDTS  transfer,  notes  about  any  non-SDTS  adjunct/auxiliary  files,  a  brief 
explanation  of  the  spatial  domain,  the  purpose,  authority  (FIPS  173),  source  (e.g.  agency 
name)  and  contacts  within  the  source  organization.  If  there  are  any  issues  about  the  transfer, 
use  of  optional  profile  annexes,  special  purposes  (i.e.  private  agreement  transfer),  non¬ 
standard  uses  of  modules,  etc.,  this  shall  be  described. 
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ANNEXES 
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Normative  Annex 


A:  The  Data  Dictionary  Transfer 


A.l  Introduction 

This  annex  describes  the  method  by  which  master  data  dictionary  transfer  will  be 
accomplished.  The  first  section  addresses  the  requirements  of  the  dictionary  transfer  itself,  the 
next  section  addresses  the  requirements  of  a  spatial  transfer  that  will  use  a  dictionary  transfer. 

A.2  Requirements  for  Master  Data  Dictionary  Transfer 

A.2.1  Required  Modules 

One  each  of  the  following  modules  is  required: 

Identification 

Catalog/Directory 

Lineage 

Completeness 

Data  Dictionary/Definition 

Data  Dictionary/Domain 

No  other  types  of  modules  shall  be  included. 

A.2.2  Required  Contents  Per  Module 

These  are  requirements  in  addition  to  those  specified  by  Parts  1,  2,  and  3.  This  information 
aids  in  precisely  identifying  transfer  contents. 

Identification  Module: 

Title  -  this  subfield  shall  include  text  to  the  effect  of  "Master  Data  Dictionary  for  ..." 

Data  Id  -  this  subfield  shall  include  the  version  number  of  this  release  of  the  master 
data  dictionary 

Data  Structure  -  this  subfield  shall  include  "MASTER  DATA  DICTIONARY" 

Data  Set  Creation  Date  -  this  subfield  shall  include  the  date  of  the  last  modify  to  the 
contents  of  the  data  dictionary 

Comment  -  this  subfield  shall  contain  a  statement  to  the  effect  of  "This  transfer  is 
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intended  to  be  used  in  conjunction  with  a  spatial  data  transfer  to  form  a  conforming 
SDTS  transfer" 

Composites  -  this  subfield  shall  contain  "N" 

Vector  Geometry  -  this  subfield  shall  contain  "N" 

Vector  Topology  -  this  subfield  shall  contain  "N" 

Raster  -  this  subfield  shall  contain  "N" 

External  Spatial  Reference  -  this  subfield  shall  have  a  null  value  meaning  "undefined, 
not  relevant;"  it  is  acceptable  to  specify  this  by  omitting  this  subfield 

Features  Level  -  this  subfield  shall  contain  the  feature  conformance  level  ("1",  "2", 
"3",  or  "4")  for  transfers  which  use  this  master  data  dictionary. 

Catalog/Directory: 

Module  Version  -  this  subfield  shall  include  the  version  number  of  this  release  of  the 
master  data  dictionary. 

Lineage: 

Comment  -  this  subfield  shall  include  a  change  log  summarizing  the  differences 
between  all  versions.  It  should  also  recommend  which  old  versions  would  best  be 
replaced  by  this  version. 

Completeness: 

Comment  -  this  subfield  shall  describe  the  product  (transfer)  series  to  which  this 
dictionary  applies.  If  applicable,  it  shall  also  note  what  subset  of  definitions  this 
transfer  contains. 

A.2.3  Version  Numbering 

Version  numbers  shall  have  the  following  form: 
d.nn 

where  d  =  a  positive  integer,  with  no  leading  zeroes,  and  nn  =  two-digit  positive  integer. 
Valid  version  numbers  are  1.01,  1.12,  and  2.13.  Invalid  version  numbers  are  01.1  and  2.1. 

Version  numbers  shall  be  incremented  according  to  the  following  rules.  The  first  released 
version  of  a  master  data  dictionary  transfer  shall  be  1.00. 
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The  number  "nn"  shall  be  incremented  when 

a)  typographical  errors  are  corrected 

b)  definitions  are  enhanced,  without  meaning  being  changed 

c)  a  domain  is  increased 

d)  unintentionally  omitted  entities/attributes  are  added 

The  number  "d"  shall  be  incremented  when 

a)  additional  entities/attributes  are  added 

b)  meaning  of  a  domain  value  is  changed 

Note:  When  "d"  is  incremented,  "nn”  shall  restart  from  "00".  A  valid  sequence  of  version 
numbers  would  be:  1.00,  1.01,  1.02,  2.00,  2.01,  2.02,  2.03,  3.00.  Invalid  sequence  would  be 
1.0,  1.10,  1.20.  Another  invalid  sequence  would  be  1.00,  1.01,  1.02,  2.03. 

The  numbering  scheme  is  intended  to  help  the  receiver  of  a  transfer  decide  which  version  of  a 
data  dictionary  is  required.  The  changes  in  "nn"  indicate  that  changes  of  a  corrective  nature 
have  been  made,  whereas  the  changes  in  "d"  indicate  that  something  new  and  different  has 
been  added. 

A.2.4  Module  Naming  Conventions 

The  modules  must  be  named  in  such  a  way  as  to  not  cause  module  name  conflicts  with  any 
module  in  a  Topological  Vector  Profile  transfer.  The  modules  shall  be  named  in  the  following 
manner: 

MIDE  Identification 

MDIR  Catalog/Directory 

MQHL  Lineage 

MQCG  Completeness 

MDEF  Data  Dictionary /Definition 

MDOM  Data  Dictionary/Domain 

A.2.5  File  Restrictions  and  Naming  Conventions 

Each  file  (ISO  8211  DDF)  shall  contain  information  from  a  single  module.  Files  shall  be 
named  using  the  following  convention: 

xxxxMIDE  Identification 
xxxxMDIR  Catalog/Directory 
xxxxMQHL  Lineage 
xxxxMQCG  Completeness 
xxxxMDEF  Data  Dictionary/Definition 
xxxxMDOM  Data  Dictionary/Domain 

where  xxxx  =  4  characters  which  uniquely  identify  the  data  dictionary. 
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Examples  are  an  agency  abbreviation  or  a  data  model  abbreviation. 

When  allowed,  the  extension  should  be  ".DDF"  to  indicate  the  type  of  file  transferred;  but  the 
last  character  of  this  extension  or  an  optional  ninth  character  on  the  base  name  may  be  used 
in  the  case  of  modules  that  span  files.  Thus  the  extension  could  become  ".DDG",  ".DDH", 
”.DDI",  ...  for  multi-volume  modules.  Such  file  extenders  are  optional.  Any  file  that  is  not 
ISO  8211  compliant  (e.g.  adjunct  files)  shall  not  have  the  ".DDx"  extension. 

A.2.6  Requirements  for  Transfer  Using  a  Master  Data  Dictionary 

The  following  restrictions  apply  to  any  spatial  data  transfer  that  requires  the  use  of  a  master 
data  dictionary. 

(a)  No  Data  Dictionary/Definition  or  Data  Dictionary/Domain  modules  shall  be 
present  in  this  transfer,  prior  to  a  merge  with  a  Data  Dictionary  only  transfer. 

(b)  This  transfer  shall  make  no  references  via  foreign  identifier  to  module  records 
of  the  master  data  dictionary. 

(c)  No  module  names  or  file  names  reserved  for  a  data  dictionary  transfer  shall  be 
used  in  the  spatial  data  transfer. 

To  indicate  that  this  transfer  requires  a  master  data  dictionary,  the  following  modules  shall 
include  the  following  information. 

Identification: 

Comment  -  this  subfield  shall  include  a  statement  to  the  effect  "This  transfer  requires 
an  external  data  dictionary  from  <agency>,  with  4-character  code  of  ...,  Version 
number  d.nn". 

Catalog/Directory: 

There  shall  be  a  module  record  in  a  Catalog/Directory  module  for  each  Data 
Dictionary  module  that  is  required  by  this  transfer. 

External  -  this  subfield  shall  contain  a  "Y". 

Module  Version  -  this  subfield  shall  contain  the  version  number  of  the  module 
referenced  in  the  Name  subfield  (of  this  module  record). 

Volume  -  this  subfield  must  not  contain  a  value. 
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A.2.7  Creating  a  Complete  Transfer 


When  external  transfer  modules  are  merged  with  a  spatial  transfer,  the  appropriate  fields  in 
the  Catalog/Directory  module  must  be  updated  -  External  set  to  "N",  and  Volume,  file,  and 
record  filled  if  information  is  present.  It  is  recommended  that  the  Module  Version  subfield 
remain  as  is,  so  version  information  is  not  lost. 
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Informative  Annex 


B:  Encoding  Multi-valued  Attributes 


Attributes  that  can  be  multi-valued  shall  be  in  their  own  tables,  along  with  any  other 
attributes  that  are  functionally  dependent.  For  example,  say  entity  "road"  has  attributes 
"num_lanes",  "name",  "oper_status",  and  "route_number."  "Name"  can  have  many  values  for  a 
single  entity  instance.  Further,  every  value  of  "name"  may  have  its  own  route  number.  Since 
the  value  of  attribute  "route_number"  is  dependent  on  "name"  then  both  of  these  are  put  in 
their  own  table.  The  modules  that  follow  illustrate  the  proper  way  to  handle  multi-valued 
attributes. 


The  line  module  LE01  references  the  attribute  records  in  the  Attribute  Primary  modules  that 
describe  the  entity  instance  being  represented.  The  attribute  module  API 2  contains  the 
attributes  that  are  not  multi-valued  for  entity  "road".  The  attribute  module  API 3  contains  the 
multi-valued  attribute  "name"  along  with  its  functionally  dependent  attribute  "route_number". 


Module  Type:  Line 

LINE 

ATID 

MODN 

ROD 

OBRP 

MODN 

RCID 

LE01 

52 

LE 

AP12 

18 

AP13 

01 

AP13 

02 

LE01 

53 

LE 

AP12 

19 

AP13 

03 

AP13 

04 

Module  Type:  Attribute  Primary 

ATPR 

ATTP 

MODN 

ROD 

NUM_LANES 

OPER_STATUS 

AP12 

18 

2 

IN  USE 

AP12 

19 

4 

CONSTRUCTION 

33 


Module  Type:  Attribute  Primary 

ATPR 

ATTP 

MODN 

RCID 

NAME 

ROUTE_NUMBER 

AP13 

01 

Main  Street 

n/a 

AP13 

02 

Highway  J 

J 

APB 

03 

1-70  N  Bypass 

470 

APB 

04 

Memorial  Expy 

155 

Repeating  the  row,  as  shown  in  the  following  modules,  is  an  undesirable  solution.  Attributes 
that  do  not  repeat  are  duplicated  in  subsequent  rows.  It  is  not  clear  whether  the  two  attributes 
with  changing  values  are  related  or  not. 


Module  Type:  Line 

LINE 

ATID 

MODN 

RCID 

OBRP 

MODN 

RCID 

LE01 

52 

LE 

API  1 

23 

API  1 

24 

LE01 

53 

LE 

API  1 

25 

API  1 

26 

Module  Type:  Attribute  Primary 

ATPR 

ATTP 

MODN 

RCID 

NUM_ 

LANES 

NAME 

OPER_STATUS 

ROUTE_ 

DESIGNATOR 

API  1 

23 

2 

Main  Street 

IN  USE 

n/a 

API  1 

24 

2 

Highway  J 

IN  USE 

J 

API  1 

25 

4 

1-70  N  Bypass 

CONSTRUCTION 

470 

API  1 

26 

4 

Memorial  Expy 

CONSTRUCTION 

155 

NOT  the  proper  way  of  handling  multi-valued  attributes. 
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Informative  Annex 


C:  An  Example  of  Attributing  Feature  Objects  with  Entity  Labels 


Module  Type:  Composite 

COMP 

ATID 

FRID 

CPID 

MODN 

RCID 

OBRP 

MODN 

RCID 

MODN 

RCID 

MODN 

RCID 

FF01 

01 

FF 

AP01 

26 

LE02 

LE02 

67 

35 

n/a 

n/a 

FF01 

02 

FF 

AP01 

42 

PC02 

23 

n/a 

n/a 

FF01 

03 

FF 

AP01 

36 

LE02 

16 

n/a 

n/a 

FF01 

04 

FF 

AP01 

37 

LE02 

96 

n/a 

n/a 

Module  Type:  Attribute  Primary 

ATPR 

ATTP 

MODN 

RCID 

ENTITY_LABEL 

NAME 

AP01 

26 

SHORELINE 

AP01 

36 

STREAM/RIVER 

JONES  CREEK 

AP01 

37 

STREAM/RIVER 

RED  RIVER 

AP01 

42 

LAKE 

SCHUMAN 

Note  that  in  this  example,  the  ENTITY  AUTHORITY  attribute  label  is  not  used.  The 
authority  for  the  definition  of  all  entity  labels  in  this  transfer  is  "USGS/NMD.”  This  example 
also  shows  a  case  where  entity  types  share  a  common  attribute  (NAME). 


Module  Type:  Data  Dictionary/Schema 

MODN 

RCID 

NAME 

TYPE 

ETLB 

EUTH 

ATLB 

AUTH 

FMT 

MXLN 

KEY 

DDSH 

201 

AP01 

ATPR 

n/a 

n/a 

ENTITY_LABEL 

SDTS/TVP 

A 

31 

n/a 

DDSH 

202 

AP01 

ATPR 

n/a 

n/a 

NAME 

USGS/NMD 

A 

127 

n/a 

35 


Module  Type:  Data  Dictionary/Definition 

MODN 

RCID 

FORA 

EALB 

SRCE 

DFIN 

AUTH 

ADSC 

DDDF 

85 

ENT 

LAKE 

USGS/NMD 

USGS/NMD  TI... 

DDDF 

86 

ENT 

SHORELINE 

USGS/NMD 

USGS/NMD  TI... 

DDDF 

87 

ENT 

STREAM/RIVER 

USGS/NMD 

USGS/NMD  TI... 

DDDF 

88 

ATT 

NAME 

USGS/NMD 

USGS/NMD  TI... 
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Normative  Annex 

D:  Arc  Option 


D.l  Introduction 

This  annex  contains  an  option  which  allows  complete  chains  to  be  composed  of  arc  and  string 
spatial  objects.  Unless  stated  otherwise  in  this  annex,  all  requirements  of  the  body  of  this 
part  also  apply  when  using  this  option. 

D.2  Spatial  Objects 

The  following  table  indicates  spatial  object  requirements  which  differ  from  that  of  section  2.1 
of  this  profile. 


Object  Representation  Code 

Required 

Optional 

Not  Permitted 

LS  -  String 

X 

AC  -  Circular  Arc 

X 

AE  -  Elliptical  Arc 

X 

AU  -  Uniform  B-spline 

X 

AB  -  Piecewise  Bezier 

X 

At  least  one  of  the  four  arc  objects  (AC,  AE,  AU,  AB)  is  required. 

All  arc  and  string  objects  must  be  components  of  complete  chain  objects  which  are 
components  of  2-D  manifolds. 

D.3  Relationship  Between  Modules  and  2-D  Manifolds 

In  addition  to  the  requirements  of  section  4.7  (a),  for  objects  particular  to  one  2-D  manifold 
there  shall  be: 

zero  or  one  Line  module  for  optional  simple  object  type  LS; 

zero  or  one  Arc  module  for  optional  simple  object  type  AC; 

zero  or  one  Arc  module  for  optional  simple  object  type  AE; 

zero  or  one  Arc  module  for  optional  simple  object  type  AU; 
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and  zero  or  one  Arc  module  for  optional  simple  object  type  AB. 

There  shall  be  at  least  one  Arc  module  for  a  particular  2-D  manifold  in  a  transfer  using  this 
option. 

D.4  Transfer  Module  Specification 

The  following  table  contains  inclusion/exclusion,  and  cardinality  rules  for  additional  modules 
permitted  by  this  annex.  The  standardized  modules  names  are  included,  along  with  the 
minimum  number  and  the  maximum  number  of  occurrences  of  the  module  type.  A  lowercase 
"n"  indicates  that  the  upper  limit  is  user  defined.  Any  lowercase  letters  or  dots  in  the  module 
name  has  the  meaning  explained  in  Section  4,  Standard  Module  Names. 


Module  Type 

Name 

Min.  No. 

Max.  No. 

Line" 

LS.. 

0 

n 

Arc 

AC.. 

0 

n 

AE.. 

0 

n 

AU.. 

0 

n 

AB.. 

0 

n 

D.5  Module  Restrictions/Requirements:  Identification  Module 

To  indicate  that  this  annex  is  being  used,  the  Profile  Identification  subfield  shall  include  "/D" 
in  the  manner  described  in  section  5.8.2  of  Part  4. 

D.6  Module  Restrictions/Requirements:  Line  Modules 

D.6.1  Chain  Component  ID 

Complete  chains  (LE  object  type)  in  transfers  using  this  annex  shall  use  this  field  to  reference 
arcs  and  strings  which  are  components  of  the  chain.  All  arcs  and  strings  in  the  transfer 
referenced  by  complete  chains  with  this  field. 

D.6.2  Spatial  Address 

Complete  chains  (LE  object  type)  shall  always  include  the  Spatial  Address  field,  even  if  the 
chain  is  composed  of  strings  or  arcs  referenced  by  the  Chain  Component  ID.  If  a  chain  is 
composed  of  strings  and  (or)  arcs,  an  encoder  shall  convert  these  strings  and  arcs  into  a  series 
of  vertices  which  shall  be  transferred  in  the  Spatial  Address  field. 


"This  Line  module  is  in  addition  to  the  Line  module  required  for  Complete  Chain  (LE)  objects  as  described  in  section 

5. 
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D.6.3  Object  Representation  Codes 


Complete  chains  (LE  object  type)  and  strings  (LS  object  type)  shall  not  be  included  in  the 
same  module. 

D.7  Module  Restrictions/Requirements:  Arc  Modules 

D.7.1  Object  Representation  Codes 

Arc  objects  with  different  object  representation  codes  shall  not  be  included  in  the  same 
module. 

D.7.2  ISO  8211  Tag 

The  ISO  8211  tag  for  the  Primary  Field  of  the  Arc  module  shall  be  ARCC.  This  is  because 
all  tags  in  an  ISO  8211  file  must  be  the  same  length  (all  other  tags  in  the  Arc  module  are 
four  characters.) 


39 


Normative  Annex 


E:  Ring  Option 


E.l  Introduction 

This  annex  contains  an  option  which  allows  GT-ring  objects  and  GT-polygon  objects  which 
are  composed  of  GT-rings.  Unless  stated  otherwise  in  this  annex,  all  requirements  of  the 
body  of  this  part  also  apply  when  using  this  option. 

E.2  Spatial  Objects 

The  following  table  indicates  spatial  object  requirements  which  differ  from  that  of  section  2.1 
of  this  profile. 


Object  Representation  Code 

Required 

Optional 

Not  Permitted 

RU  -  Ring  composed  of  chains12 

X 

PC  -  GT-polygon 

X 

PR  -  GT-polygon12 

X 

PU  -  Universe  polygon12 

X 

PW  -  Universe  polygon 

X 

PV  -  Void  polygon12 

X 

PX  -  Void  polygon 

X 

E.3  Relationship  Between  Modules  and  2-1)  Manifolds 

In  addition  to  the  requirements  of  section  4.7  (a),  for  objects  particular  to  one  2-D  manifold 
there  shall  be: 

one  Ring  module  for  optional  simple  object  type  RU. 

The  Polygon  module,  required  by  section  4.7  (a)  for  objects  particular  to  one  2-D  manifold, 
shall  contain  "PR",  "PU",  and  "PV"  objects  when  using  this  annex. 


l2Each  of  these  objects  must  participate  as  a  component  of  a  2-D  manifold. 
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E.4  Transfer  Module  Specification 


The  following  table  contains  inclusion/exclusion,  and  cardinality  rules  for  additional  modules 
permitted  by  this  annex.  The  standardized  modules  names  are  included,  along  with  the 
minimum  number  and  the  maximum  number  of  occurrences  of  the  module  type.  A  lowercase 
"n"  indicates  that  the  upper  limit  is  user  defined.  Any  lowercase  letters  or  dots  in  the  module 
name  has  the  meaning  explained  in  Section  4,  Standard  Module  Names. 


Module  Type 

Name 

Min.  No. 

Max.  No. 

Ring 

RU.. 

1 

n 

Polygon13 

PR.. 

1 

n 

A  single  module  shall  contain  only  records  of  a  single  object  type  (indicated  by  appropriate 
object  representation  code),  with  the  technical  exception  that  modules  carrying  "PR"  (GT- 
polygon)  records  may  also  contain  a  "PU"  (universe  polygon)  and  "PV"  (void  polygon) 
records. 

E.5  Module  Restrictions/Requirements:  Identification  Module 

To  indicate  that  this  annex  is  being  used,  the  Profile  Identification  subfield  shall  include  ”/E" 
in  the  manner  described  in  section  5.8.2  of  Part  4. 

E.6  Topological  Pointers 

When  using  this  annex,  GT-polygons,  universe  polygons,  and  void  polygons  shall  contain 
pointers  to  ring  objects  which  are  part  of  the  polygon;  order  is  significant,  the  outer  ring  shall 
be  referenced  first,  followed  by  any  inner  rings. 

When  using  this  annex,  GT-polygons  shall  not  have  pointers  to  their  chains. 


This  Polygon  module  requirement  is  in  place  of  the  Polygon  module  required  by  Section  5  of  this  profile. 
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Normative  Annex 


F:  Graphic  Representation  Option 


F.l  Introduction 

This  annex  contains  an  option  which  allows  the  use  of  Graphic  Representation  modules. 
Unless  stated  otherwise  in  this  annex,  all  requirements  of  the  body  of  this  part  also  apply 
when  using  this  option. 

F.2  Spatial  Objects 

This  option  does  not  add  any  additional  permitted  spatial  object  types. 

F.3  Transfer  Module  Specification 

The  following  table  contains  inclusion/exclusion,  and  cardinality  rules  for  additional  modules 
permitted  by  this  annex.  The  standardized  modules  names  are  included,  along  with  the 
minimum  number  and  the  maximum  number  of  occurrences  of  the  module  type.  A  lowercase 
"n"  indicates  that  the  upper  limit  is  user  defined.  Any  lowercase  letters  or  dots  in  the  module 
name  has  the  meaning  explained  in  Section  4,  Standard  Module  Names. 


Module  Type 

Name 

Min.  No. 

Max.  No. 

Text  Representation 

TEXt 

0 

n 

Line  Representation 

LNRp 

0 

n 

Symbol  Representation 

SYRp 

0 

n 

Area  Fill  Representation 

AFI1 

0 

n 

Color  Index 

CLRx 

0 

n 

Font  Index 

FONt 

0 

n 

F.4  Module  Restrictions/Requirements:  Identification  Module 

To  indicate  that  this  annex  is  being  used,  the  Profile  Identification  subfield  shall  include  "/F" 
in  the  manner  described  in  section  5.8.2  of  Part  4. 

F.5  Module  Restrictions/Requirements:  Catalog/Cross  Reference  Module 

If  there  is  more  than  one  Font  Index  or  Color  Index  module,  entries  in  the  Catalog/Cross 
Reference  module  shall  be  used  to  indicate  which  Font  Index  module  is  referenced  by  each 
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Text  Representation  module  and  which  Color  Index  module  is  referenced  by  each  Line 
Representation,  Symbol  Representation,  and  Area  Fill  Representation  module.  A  module  may 
not  reference  more  than  one  Font  Index  or  Color  Index  module. 


43 


t 


t 


t 


